<!DOCTYPE html>
<html lang="en">

<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Rolling a GCC Release</title>
<link rel="stylesheet" type="text/css" href="https://gcc.gnu.org/gcc.css" />
</head>

<body>
<h1>Rolling a GCC Release</h1>

<h2>Preparations</h2>

<ol start="1">
<li>Before rolling the release, update the release notes web pages
(for example <code>gcc-7/changes.html</code> and
<code>gcc-7/index.html</code>)
and ensure that they are all listed in <code>contrib/gennews</code>.
On the announcement page for that release series, note the new
release without removing information about any previous minor releases.
The <code>changes.html</code> page for that release series should have
details added of the changes in each minor release.</li>

<li>Verify that displayed copyright years include the current year.
Check at least <code>java/jcf-dump.c</code>, <code>gcc.c</code>,
<code>gcov.c</code>, <code>fortran/gfortranspec.c</code> and
<code>gcov-dump.c</code> (grep for <code>"Copyright</code>).
Also check documentation.  See SVN revision 194838 for an incomplete
example.</li>

<li>Verify <a href="https://gcc.gnu.org/PR43620">PR other/43620</a> isn't
a problem on the branch, otherwise ftp upload to ftp.gnu.org might fail.
<code>find . -name Makefile.in | xargs grep a+w</code>
or
<code>find . -name Makefile.in | xargs grep distdir:</code>
might do the job.</li>

<li>Warn developers to abstain from checking in any code on the
release branch.</li>

<li><a href="translation.html#collect">Check for new message
translations</a> and commit them to the release branch (and to
mainline if it is the most recent release branch).  <a
href="translation.html#regen">Regenerate
<code>gcc.pot</code></a> and <code>cpplib.pot</code>.</li>
</ol>


<h2>Generation and Upload</h2>

<ol start="4">
<li>Roll the release using the
<code>maintainer-scripts/gcc_release</code> script from the same
branch as the release.  You must pass the <code>-f</code> option, to
indicate a final release, the <code>-r</code> option (for example,
<code>-r 7.3.0</code>), to give the release version, and, if diffs
against a previous release are to be generated, the <code>-p</code>
option, whose argument must name the <code>.tar.xz</code> file for a
previous release, in a directory containing all the
<code>.tar.xz</code> files for that previous release (for example,
<code>-p /some/where/gcc-7.2.0/gcc-7.2.0.tar.xz</code>).</li>

<li>Upload the release to ftp.gnu.org.</li>

<li>Ensure that the upload on gcc.gnu.org also comes with
cryptographic signatures (<code>.sig</code> files).</li>

<li>Increment the version number in <code>gcc/BASE-VER</code>. 
<code>gcc/DEV-PHASE</code> remains empty. Check the file in.</li>

<li>Notify developers that checkins to the branch are once again
allowed.</li>

<li>Reenable the generation of snapshots off the respective release
branch in the crontab of gccadmin on gcc.gnu.org.</li>
</ol>

<h2>Web Site Updates</h2>

<ol start="9">
<li>Update the <code>develop.html</code> and <code>releases.html</code>
web pages.</li>

<li>Update the version numbers of the current and future releases on
the main web page, and add a proper news item there as well.</li>

<li>For a new major release, ensure that the build status page is present
and add a link from the main <code>buildstat.html</code> page.</li>

<li>Generate online documentation for the new release with
<code>update_web_docs_git</code>.  The appropriate command to run (as gccadmin)
to generate the documentation would be <code>scripts/update_web_docs_git
-r7.3.0 -dgcc-7.3.0</code> (with the current version
number inserted).  Link to it from <code>onlinedocs/index.html</code>
(but don't break URLs to documentation for previous releases even if
you remove the links to it).  Create additionally
<code>onlinedocs/<em>version-number</em>/index.html</code> by copying it
from a previous release and adjust it.</li>

<li>Generate online libstdc++ documentation with the
<code>maintainer-scripts/generate_libstdcxx_web_docs</code> script on trunk.
That currently can't be done on sourceware.org due to dependencies on a
number of DocBook and LaTeX packages. The script takes two arguments, the
root of the GCC sources (for the new release) and the output directory
for the generated files.  All the output that gets created should be placed
in the same <code>onlinedocs/<em>version-number</em>/</code> directory
as the other documentation for the release.</li>

<li>Update the online-documentation links in <code>changes.html</code>
to point to the online-documentation for the branch.</li>

<li>Update the main web page (<code>index.html</code>).</li>
</ol>


<h2>Announcements</h2>

<ol start="14">
<li>Announce the release to the gcc-announce@gcc.gnu.org, gcc@gcc.gnu.org
and info-gnu@gnu.org mailing lists.
<ul>
<li>Make sure that most mirrors have retrieved the new release already.</li>
</ul></li>
</ol>

<h2>Bugzilla Updates</h2>

<ol start="15">
<li>Create a new version in Bugzilla corresponding to the new branch
version.  This can be accomplished by choosing products, choosing gcc,
and editing the versions.  Please do <strong>not</strong> delete old 
versions.</li>

<li>Create a new target milestone in Bugzilla corresponding to the dot
release after the immediate next (for example create a milestone for
7.3 after releasing 7.1, so we can slip the milestone for PRs that
can't be fixed in time for 7.2).  This can be accomplished by
choosing products, choosing gcc, and editing the target milestones.
Please do <strong>not</strong> delete old target milestones.</li>

<li>Change all open bugs targeted at the just released milestone to be targeted
at either the mainline version milestone, or the next point-release milestone.
This can be accomplished by
<code>maintainer-scripts/branch_changer.py</code> script with the following arguments:
<br/>
<code>./maintainer-scripts/branch_changer.py api_key --new-target-milestone=10.4:10.5
--comment 'GCC 10.4 is being released, retargeting bugs to GCC 10.5.'</code>
<br/>

The script invocation changes target milestone from 10.4 to 10.5 and new comment
<i>GCC 10.4 is being released, retargeting bugs to GCC 10.5.</i> is added.

Unless you add <strong>--doit</strong>, the script runs in dry mode only. One can use
<code>--limit N</code> in order to limit the number of affected bugs.

<li>Update the bug searches on the main web page for the milestone
changes.</li>
</ol>

</body>
</html>
